End-users of computer systems often desire status information regarding print jobs. Existing system and application software provide end-users with mechanisms for obtaining print job status on current WINDOWS™ operating systems, but these mechanisms often fall short of meeting the expectations of users. These mechanisms include the “Printers” folder provided by MICROSOFT WINDOWS™ and the DOCWISE™ package provided by Hewlett-Packard Company, Palo Alto, Calif.
A WINDOWS™ user can click on a printer icon in the “Printers” folder or double-click on the printer icon in the task bar to view a window 100, as illustrated in FIG. 1, containing status information related to her print jobs. Unfortunately, this status might be more accurately called “print queue status.” The window 100 shows a list of jobs waiting to be sent to the printer. As each job is sent to the printer, it is removed from the list regardless of whether or not it has completed printing. The state of the printer is displayed provided that a job is currently printing. Most printers have a buffer of memory for accepting incoming jobs. Often, this buffer provides more than enough storage to accommodate the job. This causes all of the print job data to flow into the printer buffer, which removes the print job from the printer status window 100. The print job might suffer from any number of problems while being processed by the printer; however, WINDOWS™ has no provision for informing the user of these problems. Once the print job data has been transmitted outside of the operating system, WINDOWS™ considers the job completed successfully, despite the fact that end-users do not share this optimism and this behavior does not meet end-users' expectations.
Recognizing these problems, Hewlett-Packard has developed software that independently provides print job status. This software is called DOCWISE™. In use, DOCWISE™ displays a print job status window 200, as shown in FIG. 2, when an end-user has requested notification. If the end-user requests notification when his print job has completed, the window 200 is displayed at that time. If the end-user requests notification when a problem is encountered while processing his print job, the window 200 is displayed at that time. The notification behavior is configurable.
FIG. 3 illustrates a system memory 300 utilized by DOCWISE™. The system memory 300 is divided into a user mode segment 310 and a kernel mode segment 315. Kernel mode is a privileged operating system mode reserved for low level drivers and low level operating system components. In the user mode segment 310 of the system memory 300 are an application 320, a spooler 330, a registry 340 and a status monitor 350. The application 320 initiates a print job. Processing of the print job involves a print driver, the spooler 330 and a graphic device interface (GDI) 360, as will now be briefly described. A print driver is modified (by DOCWISE™) and resides in part in the application 320 and in part in the kernel mode segment 315. The modified print driver configuration part 370, which runs in the same address space as the application 320, is responsible for collecting information about the configuration of the job and the printer. The modified print driver translation part 375, which resides in the kernel mode segment 315, is responsible for using the collected information along with a description of the print job to produce something that the target printer can understand. At the interface between the user mode segment 310 and the kernel mode segment 315 is the GDI 360. The GDI 360 is the subsystem of the operating system responsible for handling drawing API calls, which the application 330 makes to the operating system when printing. The GDI 360 handles the drawing API calls by translating them into corresponding calls to the modified printer driver translation part 375, which then generates print data. Then, the GDI 360 sends the print data to the spooler 330. The spooler 330 forwards print data from the GDI 360 to a target printer (not shown). The spooler 330 includes a modified port monitor 380 that adds to the stream of data sent to the printer (also called “output stream” or “print stream”) a unique job identifier to facilitate tracking of the print job.
The registry 340 is a collection of settings in the WINDOWS™ operating system. These settings are used by the modified port monitor 380 and the status monitor 350. The status monitor 350 is responsible for monitoring print job status. The status monitor 350 detects the initiation of a print job and tracks the job as it is processed by the source computer system and the target printer. More specifically, DOCWISE™ detects when a print job is initiated, determines the WINDOWS™ ID (identification) of the job in order to track it within the spooler 330, and uniquely marks the job so that it can be identified within the printer. These steps will now be explained in greater detail.
The WINDOWS™ NT 4.0 operating system provides convenient APIs (application programming interfaces) that provide notification of when a job is initiated. The APIs FindFirstPrinterChangeNotification and FindNextPrinterChangeNotification can be used with the flag PRINTER_CHANGE_JOB to monitor for the initiation of a new print job. Once notified of the existence of a new job, the spooler 330 can quickly be queried for the most recently added job using the EnumJobs API. Once the job in the spooler 330 has been identified, its job ID can be obtained.
The task of marking the print stream with a unique identifier can be divided into three subtasks: (1) determining a unique identifier; (2) insuring that the unique identifier is known to the status monitor 350; and (3) inserting commands that are required to mark the print stream. DOCWISE™ constructs a unique identifier by forming a combination of the network identifier of the source computer and the local print job ID. The unique identifier is then unique everywhere on the network, not just on the local machine. The network identifier of the local machine can be stored in the registry 340 and retrieved as required. Because the registry is easily accessible to programs, the network identifier can be reliably obtained anywhere it might be required (i.e. for inserting the commands required to mark the print stream). The local print job ID is also available throughout much of the operating system. As described above, the status monitor 350 can obtain the local print job ID by immediately querying the spooler 330. The local print job ID is also made available to kernel programs (which are not able to call normal API functions), such as the modified printer driver translation part 375.
DOCWISE™ inserts the commands that are required to mark the print stream in two steps. First, the modified printer driver configuration part 370 gathers the information that is required to mark the print stream and places this information into the DEVMODE (“device mode”) data structure 385, where such print job settings as number of copies, duplex, color, etc. are stored. Next, the modified port monitor 380 uses this information to make the actual modification to the print stream.
Unfortunately, DOCWISE™ suffers from a number of problems having to do with reliability and availability. First, DOCWISE™ uses a specially modified printer driver. It can be extremely difficult to modify some printer drivers and to make the modified printer drivers available to end-users. Because many different business entities supply printer drivers to end-users, the necessary cooperation and coordination among these entities is challenging to achieve at best and impossible at worst. Second, DOCWISE™ uses a specially modified port monitor to modify the job stream. Because DOCWISE™ is linked to a particular port monitor technology, end-users wishing to use a different port monitor are unable to take advantage of the print job tracking capabilities supplied by DOCWISE™. Third, printing must occur to a local port—not a shared network queue as is often used in a network environment where print job status is most important—for DOCWISE™ to operate properly. If a remote spooler is utilized, DOCWISE™ cannot provide print status information. The first two problems, by depending on special modifications to software that may vary, result in a brittle solution that is difficult to maintain. The third problem severely limits the availability of the desired print status feature. In summary, DOCWISE™ only works under the following three conditions: (1) a printer driver must be modified; (2) a port monitor must be modified; and (3) printing must occur to a local port. Unfortunately, if these conditions are not met, the user simply does not receive print job status. As a result, the user can get the impression that DOCWISE™ behaves inconsistently.